In any real-time communication system, there is a need to adopt to a change in the transport characteristics. For example, for data transport based on the Internet Protocol (IP), this was seen already when designing the Real-Time Transport Protocol (RTP) [1] where an accompanying reporting protocol called the Real-time Transport Control Protocol (RTCP) was designed in order to enable point-to-point reporting of the experienced characteristics of the media flow. In an RTCP report, a number of different characteristics can be reported and there are provisions to use so-called extended RTCP reports (RTCP-XR) which can contain a very large amount of data. The receival of these reports makes it possible for the transmitting application/unit to change its behavior to make better use of the available channel resources.
When using a real-time communication service in an environment where the link throughput or the total end-to-end transport characteristics cannot be guaranteed, there will be a need for the application to cope with these varying circumstances. If this is not done, the session might be compromised with less than optimal quality or terminated in worst case. This is valid for all communication networks and even more so for mobile networks since the radio environment makes it virtually impossible to provide guarantees about the transport characteristics.
This is also true for circuit-switched transport. In the Adaptive Multi-Rate (AMR) speech codec used in 3GPP Circuit Switched (CS) speech services there are means to signal end-to-end requests for the codec to adapt to new measured circumstances. For example, when the Carrier-to-Interference ratio (C/I) of one of the radio links falls below a certain threshold, a request is normally sent using the Codec Mode Request (CMR) bits in the AMR bit-stream to the other end to reduce the source coding bit-rate and apply more robust channel coding.
For IP transport, RTCP can fulfill roughly the same purpose but it has a number of drawbacks, the main one being long delay between reports which forces the application to be reactive rather than proactive. The use of RTCP receiver reports will thus make the adaptation process rather slow. Even though the information in the reports is usable, any response to it will in practice be reactive rather than proactive. The quality degradation will already have occurred.
The problem of the slow response of RTCP reports has been recognized in reference [2], where a procedure based on audio packet loss prediction at the receiver is suggested. By predicting audio packet loss at the receiver side, the sender can be warned. In particular, the packet inter-arrival jitter is computed for each packet and compared to predefined thresholds to predict packet loss. It is envisaged that an abrupt change in inter-arrival time is followed by an overshoot in audio packet loss. In this way, by monitoring the inter-arrival jitter on a packet-by-packet basis it is possible to reduce packet loss by warning the sender as soon as the jitter exceeds a certain threshold value.
Although the solution described in reference [2] represents a considerable improvement compared to the slow RTCP report mechanism, the solution does not seem to provide quite satisfactory results in practical applications. In particular, the approach suggested in reference [2] seems to be much too conservative in many applications.
There is thus a general need for an improved mechanism for media layer adaptation in real-time applications.